What

CatalogSnapshot builds the compact aspect-type alias key from the wrong path segment, so the cached key starts with the literal string projects instead of the actual project id.

Why

The aspect-type resource name is projects/{project}/locations/{location}/aspectTypes/{type}. After split('/'): parts[0]='projects', parts[1]=project, parts[3]=location, parts[5]=type. The fetch uses the right segments:

const res = await catalog.getAspectType(parts[1], parts[3], parts[5]); // ✅

but the alias key uses parts[0]:

this._aspectTypes.set(`${parts[0]}.${parts[3]}.${parts[5]}`, res.result); // ❌ -> 'projects.global.<type>'

So the key becomes e.g. projects.global.bigquery-table instead of <project>.global.bigquery-table, which breaks the dedup lookup and leaks an invalid value into lookupEntry's aspectTypes query param.

Change

Use parts[1] (the project id), matching the established convention in gcp/dataplex.ts::_nameToTypeRef → ${nameParts[1]}.${nameParts[3]}.${nameParts[5]}.

Verification

npm run compile ✅ and npm run test ✅ (17 pass / 0 fail) in toolbox/mdcode.

Note for maintainers

The same one-line bug exists in the parallel agents/mdcode/src/libts/snapshot.ts copy (three sites: the success + 403-placeholder branches and the reference-aspect loop). I scoped this PR to toolbox/mdcode only because agents/mdcode currently has pre-existing compile (TS6133 unused-var) and test failures on main unrelated to this change (verified: pristine main shows the same 8 pass / 19 fail), so a green run isn't achievable there yet. Happy to extend this PR to the agents/mdcode copy if you'd prefer.

🤖 Generated with Claude Code